Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Description

Summary

The network_settings_playbook_config_generator module incorrectly reports a failure when file_mode: overwrite is used and the generated YAML content is identical to the existing file. Instead of treating it as a successful idempotent operation, it throws a write error.

Steps to Reproduce
Ensure a site (e.g., Global/Vietnam) exists in Catalyst Center.
Run the module with:
network_management_details
site_name_list: ["Global/Vietnam"]
a fixed file_path
file_mode: overwrite
Verify the file is created successfully on the first run.
Run the same command again with identical inputs.
Observed Behavior

The second run fails with an "unable to write to file" error, even though the generated content is identical to the existing file.

Expected Behavior

With file_mode: overwrite:

The file should either be overwritten every time, or
The module should return success with changed: False if content is unchanged
It should not fail in either case.

Fixed core bug (overwrite behavior)
If write_dict_to_yaml returns False (same content), it is now treated as a successful no-change (idempotent) case
Previously, it was incorrectly treated as a failure
Simplified self.msg in success cases
Changed from dictionary → simple string
Extra details are now passed separately via additional_info
Applied same fix to early success paths
Empty components_list
No matching data (both checks)
All now use simple string messages
Applied same fix to schema failure case
self.msg is now a string
Error details moved to additional_info
Corrected logging level
Changed log from ERROR → INFO when file is unchanged
Reflects expected idempotent behavior

Testing Done:

• [] Manual testing
• [] Unit tests
• [] Integration tests

Test cases covered: [Mention test case IDs or brief points]

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• All the sanity checks have been completed and the sanity test cases have been executed

Ansible Best Practices

• Tasks are idempotent (can be run multiple times without changing state)
• Variables and secrets are handled securely (e.g., using ansible-vault or environment variables)
• Playbooks are modular and reusable
• Handlers are used for actions that need to run on change

Documentation

• All options and parameters are documented clearly.
• Examples are provided and tested.
• Notes and limitations are clearly stated.

Screenshots (if applicable)

Notes to Reviewers